In communication networks, it is often very desirable to measure the performance of the communication network, e.g. by measuring round-trip-time, RTT, and other performance parameters between two nodes of the communication network. Such measurement may give an indication of the performance of the communication network.
Such measurements are typically initiated by one of the nodes and performed towards a peer node with which the initiating node is communicating. The result gives an indication of e.g. if the communication network is heavily loaded or if a failure has occurred in the communication network.
Virtualisation of networks and computers is common today. One example for computer virtualisation that can be utilised by more or less anyone is the Amazon Elastic Compute Cloud. It is a service that provides dynamic computer capacity to their customers. Also, computer virtualisation is common in data centres where resources are shared in order to increase utilisation of hardware.
In FIG. 4a which will be described in more detail below, an example of a virtualised computer is shown. Instead of running one operating system on top of the hardware, a hypervisor runs as a middleware between the virtual machines/operating systems and the hardware. The hypervisor acts as a hardware controller that manages the shared recourses among the virtual machines (in which operating systems can run). The main intent of the hypervisor is to instantiate the virtual machines, provision the resources and make sure that the resources are shared in a fair (or according to a Service Level Agreement, SLA) manner among the executing operating systems.
Active probing is an accepted method for determining performance parameters of packet-switched networks. The basic concept is to transmit probe-packets from a sender towards a receiver. Each probe-packet train is time stamped on both sides.
The Internet Engineering Task Force, IETF, Internet Protocol Performance Metrics (IPPM) working group has defined two IP active measurement protocols: One-Way Active Measurement Protocol, OWAMP, and Two-Way Active Measurement Protocol, TWAMP. OWAMP is designed for measuring one-way packet delay and one-way packet loss between two hosts or nodes. TWAMP is based on OWAMP. TWAMP is designed for measuring one-way and two-way (round-trip) packet delay and packet loss between two hosts or nodes.
The standard TWAMP protocols consist of two protocols: the TWAMP control protocol and the TWAMP test protocol. The TWAMP control protocol is used to initiate, start and stop TWAMP test sessions. The TWAMP test protocol is used to exchange TWAMP test packets between two TWAMP hosts or endpoints. Test sessions can also be configured without the TWAMP control protocol and this is known as TWAMP light.
The standard TWAMP measurement architecture is usually comprised of only two hosts with specific roles. This is known as the two-host implementation. One host plays the role of the initiator or controller and session-sender and the other host plays the role of the server and the session-reflector. In the standard architecture, the different roles can be played by different hosts.
The host that initiates the TWAMP control Transport Control Protocol, TCP, connection takes the roles of the controller and session-sender. The host that acknowledges the TWAMP control TCP connection accepts the roles of the server and session-reflector.
In a TWAMP test session, packets are time stamped, tagged with sequence numbers and transmitted from a session-sender to a session-reflector. The session-reflector time stamps the incoming packets, create new test packets (one packet is created for each test packet received by the session-reflector) and send them to the session-sender as soon as possible. Using these time stamps and sequence numbers, the session-sender can then calculate the one-way delay, jitter, round-trip time and packet loss for the session in both the forward path and the reverse path.
However, there is no way to determine how the virtualisation affects the performance between the two hosts. The impact of the virtualisation may very well be non-negligible and may sometimes be quite high. From a network diagnosis perspective, it may be important to determine and also localise the root or cause of e.g. an increased round trip time, RTT.